-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Refactor codegen backends in bootstrap #144787
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
This PR modifies If appropriate, please update This PR modifies If appropriate, please update |
This comment has been minimized.
This comment has been minimized.
@rustbot author |
588f96f
to
0a3b2d7
Compare
@rustbot ready |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I have some nits/questions
Pushed review changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, two nits because I only just noticed
4235812
to
e89c64f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks
@bors r+ rollup=never (build system changes, just in case) |
Let's run a never PR while I investigate the recent rollup failure. @bors p=1 |
Undoing my previous priority bump, since the immediate scheduling concern was solved. @bors p=0 |
e89c64f
to
1a2ee80
Compare
Rebased and blessed snapshot tests. @bors r=jieyouxu |
Refactor codegen backends in bootstrap This PR refactors the codegen backend steps, in preparation to make more progress on the integration of the GCC codegen backend in bootstrap. It does several things: 1) Splits the `CodegenBackend` step into two, one for clif and another one for gcc. Even though their code is mostly similar, that's IMO mostly fake similarity, and they do (or will) ultimately require different handling. This was already visible in the requirement of building GCC for cg_gcc, of course. 2) It is now possible to build both backends (and dist cranelift) even if they are not specified in `rust.codegen-backends`. It was quite weird that it wasn't possible to even invoke the corresponding codegen backend if the backend wasn't specified in that array, as that array should ideally only change defaults (see later below). 3) Changes the path specification of these steps to an alias. In other words, instead of `compiler/rustc_codegen_cranelift`, the step is now built only using `rustc_codegen_cranelift` or `cg_clif`. This is done to avoid an annoying clash with `x build compiler`, which would otherwise build both codegen backends after the 2) change. 4) Made the copying of codegen backend artifacts more explicit, in particular in the `Assemble` step. 5) Codifies the semantics of `rust.codegen-backends`, which now only affects the defaults of whether a codegen backend will be included in rustc's sysroot and whether it will be disted in `x dist` by default. We can change the behavior later, e.g. to dist cranelift by default in `x dist` once it becomes stabilized. Currently I left the existing behavior that we use on CI, I just tried to document it better. I don't think that this requires a change tracker entry, because the defaults should work the same as before. It is just now possible to do `x build/dist rustc_codegen_cranelift` even if CLIF is not in the `codegen-backends` array. It is no longer possible to do ` ./x build compiler/rustc_codegen_cranelift` though, not sure if that requires a change tracker entry. There is one thing that I didn't touch yet, and that is the fact that `rust.codegen-backends` not only affects the default behavior of `x dist` w.r.t. Cranelift, but also of `x test`. In other words, `x test rustc_codegen_cranelift` still does not hing if cranelift isn't in `rust.codegen-backends`. I plan to take a look at this once I get to refactoring the test steps. r? `@jieyouxu`
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
I knew it, we may need to close the tree |
@bors treeclosed=100 A test is failing on CI. I guess we just comment out the test for now? |
@bors retry |
This PR refactors the codegen backend steps, in preparation to make more progress on the integration of the GCC codegen backend in bootstrap. It does several things:
CodegenBackend
step into two, one for clif and another one for gcc. Even though their code is mostly similar, that's IMO mostly fake similarity, and they do (or will) ultimately require different handling. This was already visible in the requirement of building GCC for cg_gcc, of course.rust.codegen-backends
. It was quite weird that it wasn't possible to even invoke the corresponding codegen backend if the backend wasn't specified in that array, as that array should ideally only change defaults (see later below).compiler/rustc_codegen_cranelift
, the step is now built only usingrustc_codegen_cranelift
orcg_clif
. This is done to avoid an annoying clash withx build compiler
, which would otherwise build both codegen backends after the 2) change.Assemble
step.rust.codegen-backends
, which now only affects the defaults of whether a codegen backend will be included in rustc's sysroot and whether it will be disted inx dist
by default. We can change the behavior later, e.g. to dist cranelift by default inx dist
once it becomes stabilized. Currently I left the existing behavior that we use on CI, I just tried to document it better.I don't think that this requires a change tracker entry, because the defaults should work the same as before. It is just now possible to do
x build/dist rustc_codegen_cranelift
even if CLIF is not in thecodegen-backends
array. It is no longer possible to do./x build compiler/rustc_codegen_cranelift
though, not sure if that requires a change tracker entry.There is one thing that I didn't touch yet, and that is the fact that
rust.codegen-backends
not only affects the default behavior ofx dist
w.r.t. Cranelift, but also ofx test
. In other words,x test rustc_codegen_cranelift
still does not hing if cranelift isn't inrust.codegen-backends
. I plan to take a look at this once I get to refactoring the test steps.r? @jieyouxu